可讀性基本定理

這是什麼意思？很簡單，找個一般能力的同事，測量他們理解程式碼需要的時間，這就是撰寫程式時希望縮短的理論值。
「理解」的要求非常高，完全理解程式碼，應該要能夠修改、找出臭蟲並知道與程式其他互動的方式。
現在，讀者可能認為，「誰會在乎其他人懂不懂？我是唯一一個使用這些程式碼的人！」即使單人專案也值得追求這個目標，「其他人」可能是6個月後的自己，到時候對程式碼不再熟悉。永遠無法確定—可能有其他人加入專案，或是「被丟棄的程式碼」可能被用在其他專案當中。

最短理解時間是否與其他目標充衝突？

讀者可能會想「其他的條件怎麼辦？像是程式效率、良好的架構或是可測試性等等？這些條件難道不會讓程式易於瞭解」
但其他目標並不會受到太大影響，即使在高度最佳化程式碼中，仍有辦法讓程式碼高度可讀性，實際上讓程式碼易瞭解常常也會產生良好的架構且易於測試。
難以決定時，可讀性基本定理優於之後其他任何原則。同時，某些程式設計師無法忍受任何不完美的程式碼，這時必須停下腳步，想想程式碼是否易於理解如果已經如此，也許可以放心處理其他程式碼。

困難所在

的確，時時考慮某個假設的讀者是否能夠理解程式碼需要花費不少額外功夫，需要將大腦切換到撰寫程式時沒用到的部份才行。
但選擇這個目標，可以確定讀者能成為更好的程式設計師，產生少的臭蟲，對成品更有認同感，同時能產出其他人樂於使用的程式碼。

Reference

• <<易讀程式之美學－提升程式碼可讀性的簡單法則 >>(The Art of Readable Code)